Pas une réelle surprise cette arrivée d’Apple dans le secteur de l’éducation. Les lecteurs qui ont des enfants n’ont qu’à regarder le contenu des cartables de leur progéniture…! Et relire la bio de Steve Jobs…

Entre le poids — excessif mais cela fait des générations que cela dure — des livres transportés, l’état ce ces derniers distribués en début d’année dans les écoles publiques ou privées, l’état des ouvrages prêtés, parfois dégradés par les élèves eux-mêmes. Sans oublier, enfin, la fraicheur toute relative des contenus.

En sortant de l’école, ces mêmes mômes peuvent regarder des émissions comme C’est pas sorcier qui expliquent de manière nettement plus ludique et astucieuse des matières scientifiques vues en classe… Bon, encore faut-il que les gamins aient envie (soient sollicités, CQFD) de regarder de telles émissions, il y a tant de choses à partager via Facebook ou SMS (ironie…!). Je dois reconnaître que je suis client de ces explications interactives et schématisées, en soupirant sur le temps que j’avais passé, gamin, à piger tel ou tel principe.

Bref, entre les outils pédagogiques à l’école et les capacités de présentations disponibles sur un écran d’iPad ou autre, il n’y a pas trop à discuter même si des générations de gamins ont appris comme cela.

Reste donc à fabriquer ce foutu contenu… La réponse d’Apple me parait intelligente… iBooks Author. Produit gratuit (mais Lion indispensable), Pages mâtiné de Keynote qui ne supporte en entrée que du Word ou du Pages…

Pardon…? J’imagine que cela supporte au moins du texte arrivant par un simple copier/coller… Bien sûr…

Et en sortie, du ePub et du PDF (ouf…!). Bien entendu, tout cela peut être détourné par n’importe quel auteur, on peut réaliser avec cela autre chose que des livres scolaires ou universitaires, non…?

Bon, pas de copie d’écran de iBooks Author…? Si. Grâce à MacGeneration et Mac Bidouille, j’ai installé sur ma 10.6.8 un produit que manifestement Apple a bridé artificiellement à 10.7.2…

D’ailleurs, je suis assez surpris de pas mal de petites choses… Déjà :

Tim, si tu pouvais expliquer à tes gars que forcer les gens à passer à Lion (…encore instable alors que j’ai besoin de produire…) n’est pas la meilleure méthode…? Laisse nous choisir le moment de basculer d’un OS à un autre d’autant que iBooks Author est bien la version de Pages que nous attendions depuis des lustres… sous OSX 10.6.x…

Ensuite, c’est quoi ça dans ton EULA…?

C’est Apple ou moi qui réalise les documents que je produis…?!

Steve, reviens, les gars du marketing ont pris le pouvoir et ils font tellement de bourdes que c’est à cela qu’on les reconnait (St Audiard, Épître aux C$#€)…

Alors…?

Bon, ce billet est décousu car écrit au fur et à mesure de mes investigations…

Alors oui, on peut charger l’app en rusant…

Oui, on peux choisir une template et importer un texte (Pages ou .doc)…

Ou, ici, prendre un fichier MultiMarkdown (avec ses HUD…) et, depuis Byword, exporter en .doc…

Glisser simplement (drag and drop) des images du bureau dans l’application (…je vous fais grâce des options de Pages…) et lire la suite des pages à l’horizontale…

Organiser son contenu facilement (outliner)…

Exporter et ouvrir le bestiau dans iBooks…

Et s’en servir…!

Alors, hormis quelques points qui fâchent…

• brider artificiellement iBooks Author…
• déclarer que le contenu est Appelesque…
• limiter les imports à Word et Pages…
• limiter le .ibooks à la seule tablette iPad…

C’est quand pas mal du tout ! Bon, je vais me doucher…

À suivre…

NB : à propos des conditions édictées par Apple, souvenons-nous d’un précédent (DropBox) que Marc avait magistralement expliqué ici-même…

Bon, je suis un peu plus rentré dans MultiMarkdown Composer (voir sur urbanbike) pour des raisons d’urgence personnelle et, je croise les doigts, cela semble tenir la route. Plutôt que de poursuivre avec un dispositif brinquebalant (et dans dans ce mot, il y a lent…!), j’ai carrément changé mon fusil d’épaule. À confirmer pour la suite…

Je continue à utiliser plus que jamais Byword et Day One pour pondre mes fragments de texte mais l’assemblage se fait sur Composer.

Pour mon confort, j’ai…

• Modifié la feuille de style. J’ai ouvert le contenu du paquet de l’application, histoire de dupliquer une feuille de style que j’ai ensuite placée dans un répertoire créé pour l’occasion dans ma bibliothèque système. Puis, via BBEdit, changé quelques paramètres pour retrouver une ambiance à la Byword matinée de MultiMarkdown Composer.
• Découvert que coller les URL sur une sélection crée la balise Markdown, sympa. Certes, Byword reste plus confortable mais ce système n’est pas mal du tout.
• Mieux, j’ai à disposition une fenêtre (à gauche dans la copie d’écran) pour ajouter toutes mes références d’URL qui sont, elles, disposées à la fin de mon document avec un HUD, ce qui me permet (c’est le principe du Markdown) de n’avoir les URL complètes qu’une seule fois.
• Sommaire. Je ne parle pas plus du sommaire latéral déjà évoqué qui me permet, bien sûr, de me balader dans mon texte. Je rêve juste de pouvoir déplacer les items de ce dernier pour réorganiser ma structure sans passer par un copier coller (il semble que le développeur se penche sur la question).
• Enfin, la prévisualisation est effectuée sur mon Mac via Marked avec l’emploi d’une seconde feuille de style (une CSS classique).
• J’utilise également Marked pour exporter, soit en RTF, soit en PDF (images + liens). Juste que je fais pas exporter en PDF mais imprimer et choisis ici PDF pour générer un découpage correct de mes pages et non me retrouver face à une longue colonne en PDF…!

Ce qui me manque…?

Hormis l’option outliner évoqué précédemment, un export dans l’un de ces deux produits au format ePub, tout simplement…! Et, bien sûr, une passerelle vers indesign…

Pour moi, assurément, c’est la fin du .doc obligatoire et des applications aux formats de fichiers propriétaires. Côté bénéfices, c’est se concentrer sur mon texte et non sur une pseudo mise en pages. La promesse du Markdown est tenue côté portabilité : mes fragments de texte pondus sur Day One, Daedalus touch, iA-Writer ou autres se retrouvent, a terme, dans la même marmite de signes…!

Reste à cuisiner et à assaisonner l’ensemble. Et là, ça ne dépend plus que de moi…!

Non, cessez de raisonner comme avec un document Word. Les fichiers Markdown n’intègrent pas les images en leur sein comme un simple .doc !

De fait, pensez au html.

• oui, les document Markdown montrent des images dès lors que vous avez créé un lien vers elles.
• oui, il n’est pas inutile de créer un dossier sur votre machine où vos images seront systématiquement placées, rangées.
• oui, il reste à créer un lien (du code basique) entre ce dossier et votre document et c’est tout !

Cela peut être en local…

![title]\(file://localhost/Users/moi/Documents/mon_dossier/mon image.png)

ou sur un serveur…

![@quoi]\([url=http://mon_site.com/mon_dossier/mon_image.png]http://mon_site.com/mon_dossier/mon_image.png[/url] "info")

Cela évite de créer des fichiers lourdement pénalisés par des images souvent difficiles à extraire (vous n’avez jamais eu de .doc chargées d’images) et, surtout, via la feuille de style idoine, de réduire automatiquement toutes les images à une représentation de “n” pixels en largeur par exemple.

Enfin, pour afficher le tout, une simple preview.

Avantages

• De ne pas interférer avec le texte lorsque l’on rédige ! L’image reste lisible/visible via son code et comme elle est renseignée, on sait — généralement — ce qu’elle montre, pas la peine de la voir à tout bout de champ. Si l’on a oublié, hop, on prévisualise et le tour est joué…
• De ne pas alourdir le fichier texte qui reste léger, les images étant bien au chaud dans leur dossier…
• Ces images ne sont utilisées que lors de la preview ou de l’export en PDF par exemple.
• On peut conserver le format natif (et donc très lourd) des images sans pénaliser l’ensemble…

Et d’autres arguments que j’oublie certainement.